Hello @hyperfinitism,

Currently reviewing and testing on my side. Just had a quick question for you. With these changes would the -a (previously -p) flag still be needed?

What I mean by this is that if someone builds with the hyperv feature enabled, then could we make it so that they only request reports from the TPM? or if hyperv is enabled they could still get reports from either the asp and the tpm?

About the flag name

The former --platform flag was originally named to indicate that the report was obtained using platform-prepared REPORT_DATA, in contrast to --random, which uses a randomly generated nonce.

However, as already mentioned, this name is misleading. In reality, at VM boot time, the paravisor running at VMPL0 requests an attestation report from the ASP and writes it into the vTPM NV index. The command snpguest report --platform merely reads this pre-existing report; it does not request a new report using REPORT_DATA prepared by the platform at invocation time.

In this PR, the behaviour is fundamentally different. The guest OS provides 'user data' to the paravisor (via the vTPM NV index), the paravisor derives REPORT_DATA from it, and then requests a fresh attestation report from the ASP using that REPORT_DATA. Since the semantic meaning of the flag changes completely, I believe it is better to rename it rather than keep the old name.

As an alternative, for backward compatibility, we could keep the existing --platform flag for the functionality "retrieve the report and REPORT_DATA currently stored in the vTPM", and introduce a new flag --azure-cvm specifically for requesting a fresh report via the paravisor.

Behaviour when built with the hyperv feature

Even when built with the hyperv feature, the user can still attempt to request a report via /dev/sev-guest by not specifying the --azure-cvm flag.

However, at the moment, Azure CVM hides /dev/sev-guest from the guest OS. As a result, such a command will always fail on Azure CVM.

Yeah I understand the differences. What I'm asking is that if it would make sense to only request reports from the NV index if the tool was built with the hyperv feature, essentially removing the --azure-cvm flag. Or is there a reason that we would want to keep the functionality to get it from /dev/sev-guest in a hyperv snpguest. I guess for people that would want to share the same snpuguest binary between azure guests and regular linux ones, but I'm open to hear your thoughts.

I don't really mind keeping the backward compatibility for --platform since this addition will be a breaking change regardless.

Remove the --platform (--azure-cvm) flag, and fully determine behavior of the report command solely by the build feature, meaning:

• Build with hyperv → Always request reports via /dev/tpm*
• Build without hyperv → Always request reports via /dev/sev-guest

Is my understanding correct? I agree this approach represents a very natural and clean design. It simplifies both the CLI interface and the internal logic.

On the other hand, as you pointed out, the current approach of a single binary with hyperv support handling both environments at runtime offers equivalent benefits. In practice, users may want to reuse the same binary across:

• regular SEV-SNP CVMs,
• Azure CVMs powered by OpenHCL, and potentially
• future environments (e.g. CVMs with SVSM-vTPM).

@hyperfinitism where is the documentation for the NV index 0x01400002 ?
How did you configure your Azure VM to make it work?

thanks

@elmarco
The details for Azure CVM attestation can be found in Confidential VM Guest Attestation Design Detail. This documentation was first published in Jul 2024, after the --platform flag was introduced in #16 (Aug 2023).